В этом видео мы обсудим не просто миграцию базы данных, а колоссальную задачу Discord.
инженеры приступили к перемещению триллионов сообщений из одной базы данных в другую.
Если вы когда-нибудь задумывались, что нужно для переноса данных такого невообразимого масштаба,
тебе это понравится. Давайте погрузимся прямо в.
Мне не терпелось поговорить на эту тему с тех пор, как я присоединился к Discord.
Инженерная культура здесь динамичная и инновационная,
и эта история является прекрасной иллюстрацией этого. Хотя это все из публичного
информация, идеи и выводы являются моими собственными.
Недавно Discord приподнял завесу над тем, как они перенесли триллионы сообщений.
от Cassandra — базы данных, в которой хранятся ваши чаты и разговоры,
на ScyllaDB — более быстрая и надежная альтернатива.
Процесс был впервые представлен на саммите ScyllaDB Summit 2023 Бо Ингрэмом,
затем подробный пост в блоге.
Большое спасибо Бо за столь ясное представление этого сложного процесса.
Итак, чем поделился Бо? Подведу итоги и поделюсь своими выводами. Ты можешь
посмотрите его видео и прочитайте его сообщение в блоге, если вы хотите узнать об этом больше.
Отмотаем на несколько лет назад. Дискорд оказался в
немного рассол с их выбором базы данных.
Они использовали Cassandra, но в качестве платформы
продолжали расти, они столкнулись с серьезными проблемами производительности.
Потребовалось много усилий, чтобы поддерживать основной кластер Cassandra, в котором хранились сообщения.
Задержка была непредсказуемой, а частые инциденты по вызову создавали огромную нагрузку на команду.
К 2022 году кластер Cassandra содержал триллионы сообщений на 177 узлах.
Они знали, что им нужно что-то другое,
но этот кластер сообщений был критическим для Discord. Если кластер сообщений работает медленно,
Дискорд будет медленным. Если кластер сообщений не работает, Discord тоже не работает.
Их решение? ScyllaDB, совместимая с Cassandra база данных,
но с более мощным движком на основе C++ под капотом.
Вместо того, чтобы прыгать с головой, чтобы решить самую рискованную и самую большую проблему,
они начали миграцию с небольших баз данных.
И это мой первый вывод. В Discord инженеры работают быстро, когда ошибки обратимы,
но если решение представляет собой дверь с односторонним движением, они тратят гораздо больше времени и усилий, чтобы сделать это правильно.
Они использовали эти небольшие миграции как возможность проверить воду и железо.
решить как можно больше проблем, прежде чем заняться большим зверем, в котором хранились триллионы сообщений.
Давайте немного поговорим о ScyllaDB. Он был написан на C++ и обещал лучшую производительность.
более быстрый ремонт, а главное, без вывоза мусора. Для команды, которая имела
так много проблем со сборщиком мусора Кассандры, это был глоток свежего воздуха.
Следующим ключевым шагом было создание промежуточного слоя между
Монолит API и кластеры баз данных, называемые службами данных. Слой был написан на Rust,
который является безопасным и высокопроизводительным языком. И писать на Rust одно удовольствие.
Действительно крутая идея насчет этого слоя — это то, что называется объединением запросов.
Если несколько пользователей запрашивают одни и те же данные, база данных только
нужно запросить один раз. Это резко снизило вероятность возникновения горячих перегородок.
Представьте себе все эти непреднамеренные сообщения @everyone на очень популярных дискорд-серверах.
С этим промежуточным слоем для базы данных вообще нет проблем.
Потом придумали концепцию
супердиска. Кластеры базы данных работают в Google Cloud.
Столкнувшись с проблемами задержки диска, они не могли полагаться на локальные твердотельные накопители NVMe на
виртуальные машины для хранения критически важных данных из-за проблем с надежностью и долговечностью.
Альтернативой были постоянные диски Google Cloud. Хотя он был надежным и гибким, он
недостатком более высокой задержки, поскольку они были подключены к сети, а не напрямую.
Итак, что сделал Дискорд? Они вернулись к чертежной доске и сосредоточились на создании
решение с учетом их конкретных потребностей. Они решили отдать предпочтение чтению с диска с малой задержкой.
все остальные метрики диска при сохранении существующей гарантии безотказной работы базы данных.
То, что они придумали, было супер-диском, сочетающим в себе лучшее
локальных SSD и постоянных дисков на программном уровне.
Их супердиск представлял собой двухуровневое решение RAID. Они использовали RAID0 для объединения нескольких локальных твердотельных накопителей.
в один виртуальный диск с малой задержкой, а затем RAID1 для зеркалирования этого массива RAID0 с помощью постоянного диска.
Затем они настроили ядро Linux для прямой записи на постоянный диск, который раньше
гарантия надежной работы и чтение на локальные твердотельные накопители с низкой задержкой. Эта установка
обеспечивают малое время ожидания при чтении с локальных твердотельных накопителей и надежность записи с постоянных дисков.
Что в этом такого замечательного? Это отличный пример решения проблем
из первых принципов. Discord имел дело с проблемой, которая не имела
готовое решение. Вместо того, чтобы пытаться обойтись тем, что было доступно,
они переопределили проблему, основываясь на своей специфике.
ред., а затем построил соответствующее решение.
Супердиск заработал. При пиковой нагрузке базы больше не стояли в очереди
дисковых операций, и они не заметили изменений в задержке запросов.
Наконец, со всей этой подготовительной работой,
пришло время перенести их самую большую базу данных - «сообщения cassandra»
кластер. С триллионами сообщений и почти 200 узлами это была непростая задача.
Но с недавно написанным средством миграции данных на Rust и некоторыми умными стратегиями,
им удалось сделать это всего за девять дней! Да,
вы не ослышались — они перенесли триллионы сообщений без простоев менее чем за две недели!
А отдача? Значительно более тихая и эффективная система.
Они перешли от 177 узлов Cassandra к 72 узлам ScyllaDB. Это
значительно улучшились задержки и качество жизни дежурного персонала.
Это была необычная задача, но с умным снижением риска.
и инновационные решения, они справились.
Итак, у вас есть это. Я невероятно горжусь тем, что удалось сделать команде.
Миграция производственной базы данных — это не шутки, а делать это в таком масштабе… ну, это сложно.
Если вам нравятся наши видео, вам также может понравиться наш информационный бюллетень по проектированию систем.
Он охватывает темы и тенденции в проектировании крупномасштабных систем, которым доверяют 400 тысяч читателей.
Подпишитесь на blog.bytebytego.com.